The present invention relates to the field of disk drives, and in particular, to a method and system for managing defects in a disk drive system.
Modern disk drive systems include multiple disks or platters (known as the disk media) on which data is stored magnetically. Virtually all disk drive media has some defective areas where it is impossible to reliably record (write) or play back (read) data that has been previously recorded. A standard feature of disk drives is to implement some type of defect management scheme, which is designed to avoid these defective areas for the purpose of read/write transfers.
One of the common defect management techniques employed is to simply xe2x80x9cslipxe2x80x9d defective blocks. This means that in the logical order of how blocks are transferred, certain blocks are simply skipped over. For example, assuming that all blocks on a disk drive have a physical block address (PBA), and all user blocks of the same disk drive have a logical (user) block address (LBA), a drive may be laid out as shown in FIG. 1. In this simplified example, the drive has 20 physical blocks (0 through 19) and 16 user blocks (0 through 15). Therefore, up to four blocks can be slipped. The remaining blocks denoted as xe2x80x9cRxe2x80x9d are reserved for these slips.
To slip a block means to alter the LBA to PBA mapping function such that the PBA block has no LBA, and therefore will not be part of a user transfer. Assuming PBAs 3 and 12 are found to be defective and slipped, the PBA to LBA relationship now becomes as shown in FIG. 2. The blocks denoted with xe2x80x9cSxe2x80x9d are the slipped defective blocks, and the blocks denoted xe2x80x9cRxe2x80x9d are still available for slips.
The major advantage of block slipping is that it introduces minimal performance loss. A multiple sector transfer is only interrupted by a slipped block for the amount of time it takes to go past the slipped block. However, since the slipping of a defective block causes a different logical to physical relationship for all blocks after that defective block, and user data is expected to remain at a given logical block address, this technique requires the moving of all user data after a defective block has been slipped. This is a dangerous procedure since user data can be lost if there is a power or software failure, and furthermore, the time it takes generally makes the procedure prohibitive in the user environment. Therefore, this technique is rarely employed for defects found after the factory test process. It is most commonly used to identify and de-allocate the initial defects on the media before any user data is stored.
Sometimes, additional defects will appear after the factory test process, either due to incomplete defect finding in the factory, defects created because of shock or contamination, or due to environmental conditions or degradation of the magnetics after the disk drive has been placed into service. These defects are commonly referred to as xe2x80x9cgrownxe2x80x9d defects. Since the block slipping technique has the disadvantage of requiring that user data be moved after the slipping operation, typically an alternate method of defect management is employed for grown defects. A common technique is to relocate all transfers directed to a block with a grown defect to an alternate known good block. A few common terms for this technique are xe2x80x9calternatingxe2x80x9d, xe2x80x9crelocatingxe2x80x9d or xe2x80x9creassigningxe2x80x9d a defect.
With this relocating technique, one or more groups of contiguous PBAs are reserved for use as alternate destinations. When a block is relocated, an association is made between it and one of the reserved blocks. Transfers directed to that defective block will thereafter be redirected to the reserved alternate destination block instead. This technique does not affect the physical location of any other user blocks, and therefore it is more suitable for defects found in the field. It has the disadvantage of slower access when the relocated block is part of a multiple block transfer, since a seek operation and/or extra disk revolution(s) are required to get to the alternate block.
FIG. 3 shows an example relationship between PBAs and LBAs with both slipping and a reserved alternate area for future relocations. In this case, PBAs 8, 9, and 10 are the reserved alternate area. PBAs 3 and 12 have been slipped. PBA 19 remains available as an alternate area should another block need to be slipped. If, for example, LBA 4 was determined to be defective and in need of relocation, the mapping would change to look like that shown in FIG. 4. Note that in FIG. 4, the technique requires the relocation of only the defective block. Other user blocks are not affected. However, any multiple block transfer that includes LBA 4 must now transfer the blocks out of order, which may entail a seek operation and/or extra disk revolutions, and will degrade performance. Also, any multiple block transfer that is interrupted by the area reserved for alternate destination blocks will incur a performance loss.
Three important factors to consider when implementing a block relocation defect management scheme are the size, location, and number of the areas reserved for alternate destinations. The criteria upon which design decisions are made may include: (1) the disk capacity and expected number of grown defects per unit of capacity; (2) the maximum seek length required to access a relocated block; and (3) the likelihood that the area reserved for alternate destinations will interrupt a multi-block transfer.
The problem is that these parameters are highly dependent on the capacity of the drive and the configuration of the drive (cylinders, heads, sectors, recording zones, frequencies, usable radius and so forth), and many disk drives implement some or all of these parameters in a dynamic fashion. For example, it is common practice for a disk drive manufacturer to produce a line of disk drive products, each model using substantially the same design, but containing a different number of recording heads and/or disks to provide varying capacities to allow the manufacturer to sell the different products at different price points. Lower capacity models are often referred to as xe2x80x9cdepopulatedxe2x80x9d disk drives. It is still advantageous, however, to use a common electronics and firmware set for all of the different products, because it simplifies the build process, reduces time to market, and reduces costs. It therefore becomes a requirement of the firmware that it can adapt itself to the capacity of the specific model into which it is installed.
It is also common practice in the disk drive industry to depopulate a disk drive without actually removing any heads or platters. This typically happens in the factory test process when it is determined that a given recording head and surface does not meet specifications, and is therefore unsuitable for the storage of user data. In this case, the disk drive is sold as a lower capacity model. Typically, the test process will record in non-volatile memory on the disk drive (usually the disk) which surface or surfaces are not to be used. The disk drive firmware must be designed to check this non-volatile memory and automatically adjust itself to the depopulated configuration. The alternative would be to change the firmware to a set that specifically avoids the bad surface(s), however, as mentioned above, this adds manufacturing cost because multiple firmware sets must be created and supported.
Similarly, a practice sometimes used is to xe2x80x9cshort strokexe2x80x9d a disk drive that cannot reliably read and write at the extreme radius of a given surface, thus reducing capacity by not using the outer areas of the media. Instead of not using the entire surface, only a portion of the given surface is unused. Again, the firmware typically must detect this and not use the entire radius of the defective surface, so that the drive can be sold as a lower capacity model.
Another common practice in the disk drive industry is for the factory test process to detect the maximum bit density at which each installed head/media combination is capable of operating, and to dynamically adjust certain recording parameters such as the radius at which recording frequency zone boundaries are placed. This is often referred to as xe2x80x9cadaptive zoningxe2x80x9d. This results in a different number of physical and user blocks on different surfaces, and potentially a different capacity on the entire drive, which may or may not be sold as a different model depending on it""s final capacity. In this case, the firmware must detect the configuration as determined in the factory test process and adapt itself to it.
Removable media disk drives are often required to support older, lower capacity versions of the media. Often, the drive must spin up and read from some reserved areas before the capacity and configuration of the media is known. In existing systems, when adapting to the capacity or geometry of a given disk drive, the firmware does not adapt the number, size, or locations of areas reserved for alternate reassignments, it simply uses the values for one of the possible capacity models. This results in a sub-optimum defect management scheme in terms of the number, size, and locations of reserved alternate areas.
There exists a need for a block relocation-type defect management scheme whereby the size, location, and number of reserved alternate areas can be configured dynamically when the capacity and/or configuration of the disk drive is determined. It is against this background, and the desire to solve the problems of and improve on the prior art, that the present invention has been developed.
The present invention relates to a method for configuring reserved alternate areas in a disk drive system for relocations of blocks thereto. The method includes: spinning up the disk drive system, determining the configuration of the disk drive system; determining the number, size, and location of the reserved alternate areas; and storing the number, size, and location of the reserved alternate areas in memory.
The operation of determining the configuration may include determining a capacity of the disk drive system. The operation of determining the configuration may include determining information about the number and location of read/write heads in the disk drive system. The operation of determining the configuration may include detecting the number of read/write heads in the disk drive system. The operation of determining the configuration may include reading configuration information from memory associated with the disk drive system. The operation of determining the configuration may include reading an externally configurable input. The operation of determining the configuration may include receiving information from a host computer.
The operation of determining the number, size, and location of the reserved alternate areas may include scaling the size to the capacity of the disk drive system. The operation of determining the number, size, and location of the reserved alternate areas may include placing at least one reserved alternate area on each recording surface of the disk drive system. The operation of determining the number, size, and location of the reserved alternate areas may include varying the size of the reserved alternate areas depending upon the radial location of the areas on disk media of the disk drive system. The information can be stored in the form of a table. The method may further include factoring the stored information in memory into address calculations. The operation of factoring may include a fixed routine that can perform the factoring based on the information stored in the table. The method may further include factoring the stored information in memory into address calculations.